When debugging or optimizing software, it is useful to understand its timing-related behaviour (e.g. how much time was spent executing each function, each thread, or perhaps how long was spent between multiple arbitrary points in a program). This allows the software developer to decide where to focus their attention in order to improve the runtime or efficiency of their software. It also allows the hardware designer to understand the “whole system” effect of programs running with complex real-time peripherals, data sources etc. so that they can improve designs of future systems.
These debugging and optimization activities are typically performed using a debugger or profiler tool (henceforth referred to as “Debug Tool”) which extracts information from the software (henceforth referred to as “debugee”) executing on the target hardware (henceforth referred to as “target”). The target is typically an embedded device such as a mobile phone, set top box, or engine management system.
“Debug Tools” are typically implemented as either fully target-based tools or host-target tools.
Fully target-based means the debug tool executes on the same target as the debugee, i.e. all the debugging or profiling information is gathered and displayed by software running on the target. A problem with fully target-based tools is that they are typically limited by the resources available on the target system (e.g. spare memory, spare MHz required to run the debug tool, method to accept input such as keyboard, and display output such as a graphical or text display). Further, the target-based tool can perturb the debugee running on the target, i.e. such that the act of observation actually affects that which is being observed. Nonetheless, target-based tools can be useful for final “deeply embedded” test situations.
Host-target tools (sometimes referred to as “Cross development Debug Tools”) refers to tools whereby a host computer (such as a Linux or Windows based PC system) executes the main part of the debug tool and communicates with the target system which is executing the debugee to obtain debugging or profiling information. In this case the host is typically connected to the target (typically an embedded system such as a mobile phone or Set Top Box, or engine management system) by a debug link (such as a JTAG port, or NEXUS 5001 AUX port). However it can also be connected by other non-debug specific means (e.g. serial port, USB port, shared memory etc.).
Host target based tools are the most appropriate to debug and profile hard-real-time and embedded systems as the debug tool executes on a separate computer system and thus is not limited by the resources available on the target system (e.g. a PC typically provides a large amount of virtual memory, hard disc file storage and Ethernet support, whereas a mobile phone typically does not). Additionally, operation of the Debug Tool (e.g. redrawing a GUI, or processing information) does not perturb the debugee as the target is not involved.
Some of the typical timing-observation features provided in debug tools allow the software developer to: measure time spent in each function in the debuggee, measure time between arbitrary points in the debugee, measure time spent in each thread in an RTOS-based debugee, and/or measure time spent when IDLE in an RTOS-based debugee.
The resolution of the timestamps required depends on the activity being performed. For example when performing high-level analysis of time spent in individual function(s) in the program, then “system time” (i.e. μSecs or mSec) timing resolution is acceptable. But for other activities (e.g. in depth analysis of a program executing on a CPU and its interaction with caches/memory systems/peripherals etc.), then full CPU-frequency timing-resolution is desirable.
Timestamps can either be generated implicitly or explicitly when trace information is generated, or they can be added by the debug tool when it receives the trace information. Examples of the use of timestamps in debugging can be found in U.S. Pat. No. 5,790,840 and US application no. 2007/0239972.
Although host-target based tools are more appropriate to hard-real-time and embedded systems as mentioned above, there are also problems in that the time-stamping functionality and/or resolution may be limited.
Thus it can be seen that when trying to implement a debugging tool there is a problem in balancing the functionality of the debugging tool and the resolution of the time-stamping against the perturbance to the debugee and the availability of resources of the target.